Modem businesses rely increasingly on their ability to communicate with customers and other businesses in a fast, efficient manner around the clock. Most businesses use some form of automated transaction processing equipment that includes hardware and software to receive and route transactions such as telephone calls, electronic mail messages, voice mail messages, and network sessions. For example, a securities firm may use automated transaction processing equipment to answer the telephone, extract identifying information from the caller (such as an account number), access stored information about the caller and/or the caller's account, and use the information to route the call to an agent. An agent may be another automated transaction processing device or a human agent who has a telephone and a computer terminal.
Many automated transaction processing systems use computer/telephony integration (CTI) which is a process that allows telephony signals and computer-based signals to interact. For example, a particular CTI application allows computer applications to answer incoming calls, and to provide information, typically from a database, on-screen at the same time the call comes in.
For businesses that use automated transaction processing systems, it is extremely useful to be able to collect and analyze data about incoming transactions. For example, a securities firm may wish to determine how many telephone calls are completed per time period in a particular geographic area. This would allow more efficient scheduling of human agents to man telephones. A securities firm may also wish to know how much money a particular caller has invested with the firm and what types of investments a particular caller is interested in so that information about investments that would be particularly interesting to that caller may be mailed to him or her.
Using telephone calls as an exemplary transaction, typical automated transaction processing systems generate multiple messages related to each incoming telephone call. These messages are sent to other devices and software applications of the system as necessary to completely handle the incoming call. For example, when a telephone call is originally received, a message may be generated for that telephone call that is related to the way in which it should be routed. The message related to routing is sent to a routing process or application. These messages may be used to log information about incoming calls, but existing methods of logging messages have several serious limitations. For example, messages may be routinely logged by the equipment that generates the message on receipt of a telephone call. These messages are typically stored in a text format with various parameters. For example, one prior art call message includes five parameters. As is known, a parameter is a value that is given to a variable, either at the beginning of an operation or before an expression is evaluated by a program. Until the operation is completed, a parameter is effectively treated as a constant value by the program. A parameter can be text (an alphabetic parameter), a number (a numeric parameter), a combination (an alphanumeric parameter), or an argument name assigned to a value that is passed from one routine to another.
Four of the five parameters included in prior art call messages are numeric and one is alphabetic or alphanumeric. At the receiving point, only the first four numeric parameters can be stored because the equipment at the receipt point essentially only recognizes numeric characters from a telephone keypad. Some of the most important information about a telephone call, however, is stored in the fifth parameter, which is alphanumeric. For example, an account holder's name may be stored in the fifth parameter. Therefore, any alphanumeric or alphabetic information will not be available, even though the message to which it belongs is logged at receipt.
Another disadvantage of logging messages related to incoming calls at the receipt point is that the logs used to store the information are typically cyclical logs that are overwritten in turn. For example, in a system including eight cyclical logs, a log may be overwritten in minutes in a high call volume situation.
An additional disadvantage of this logging method is that access to log files is strictly through a text editor or some kind of access tool designed by the supplier of the equipment. Therefore, it is not possible to extract a formatted report using a standard database query language such as would be possible if the information were stored in a relational database. For these reasons, messages currently generated for incoming calls are of little use for record keeping or compiling of statistical information. They are used mostly for debugging.
Another prior art method of using messages generated for incoming calls logs the messages and their accompanying parameters at a later point in the call processing flow. That is, after the call is initially received and sent to a particular routing application, the routing application logs the messages it receives for a call along with its parameters. The routing application logs all five parameters, including the alphanumeric parameter. However, the information logged is in a text format rather than a relational database format. Therefore, it is, again, not possible to easily generate reports using the information. Another disadvantage of this method is that a routing application does not receive messages related to every call received but only those related to particular calls that go to that particular routing application. Therefore, truly complete information regarding calls received is not available at the routing application.